1. Field of the Invention
This invention relates to computer security and more particularly relates to providing a trusted and secure computing platform.
2. Description of the Related Art
With the advent of personal computer system use in every day business transactions, the issue of computer security has become critical. Unsecured personal computers inhibit electronic business (e-business) because users are reluctant to transmit highly personal and sensitive information to a system which may be vulnerable to intruders or viruses. While many personal computer (PC) manufacturers have made individual strides towards increasing security by adding “smart cards” or embedded security chips to their new models, the lack of a concerted effort by the PC industry to develop security technology could prevent the evolution of this technology in a consistent and compatible way between manufacturers.
Recognizing this potential risk and the adverse effects it could have on inhibiting electronic commerce, an open alliance between major PC manufacturers and developers was formed to develop and propose a standard that would adopt hardware and software technologies to strengthen security at the platform level. The open alliance, known as the Trusted Computing Group (TCG), has proposed a standard including new hardware, Basic Input Output System (BIOS) and operating system specifications so PC manufacturers can provide a more trusted and secure PC platform based on common industry standards, the details of which are provided in the TCG PC Specific Implementation Specification, Version 1.1 (Aug. 18, 2003) (http://www.trustedcomputinggroup.org), hereby incorporated by reference.
FIG. 1 is a block diagram illustrating a trusted platform in accordance with TCG standards. As is shown, the PC architecture includes a system 100, platform 120, motherboard or planar 130, and trusted building block (TBB) 140. The system 100 includes the platform 120 and all post-boot components 112, including an operating system 114, that comprise the entire entity that performs actions for, or acts on behalf of, a user. The platform 120 presents and receives information to and from the user. The platform 120 includes the motherboard 130 and peripherals 122 attached to motherboard 130.
The motherboard 130 is provided by the manufacturer and includes one or more CPUs 132 and all primary peripheral devices 134, i.e., devices that directly attach to and directly interact with the CPU 132. In addition, the motherboard 130 includes all BIOSes 136 and the TBB 140. The TBB 140 is the center of the trusted platform, and includes a Core Root of Trust for Measurement (CRTM) 142, a Trusted Platform Module (TPM) 144, and a trusted connection 146 of the CRTM 142 and TPM 144 to the motherboard 130.
According to the TCG specification, the CRTM 142 and the TPM 144 are the only trusted components on the motherboard 130, i.e., they are presumably secure and isolated from tampering by a third party vendor or software. Only the authorized platform manufacturer (or agent thereof) can update or modify code contained therein. The CRTM 142 is the executable component of the TBB 140 that gains control of the platform 120 upon a platform reset. Thus, for all types of platform resets, the CPU 132 always begins executing code with the CRTM's 142 platform initialization code. The trust in the platform is based on the CRTM 142, and trust in all measurements is based on its integrity.
The basic premise underlying the trusted platform is ensuring that untrusted devices or software have not been loaded onto the system. Trust is established during a pre-boot state that is initiated by a platform reset. The platform reset can either be a cold boot (power-on), a hardware reset, or a warm boot typically caused by a user keyboard input. Following a platform reset, the CPU 132 executes the CRTM's 142 platform initialization code. The chain of trust begins at the CRTM 142.
In this architecture, the BIOS includes a Boot Block 150 and a POST BIOS 136. The Boot Block 150 and the POST BIOS 136 are independent components and each can be updated independent of the other. The Boot Block 150 is located in the CRTM 142, while the POST BIOS 36 is located outside the TBB 140. Thus, while the manufacturer or a third party supplier may update, modify or maintain the POST BIOS 136, only the manufacturer can modify or update the Boot Block 150. In a variation of the architecture, the entire BIOS is a single entity located entirely within the CRTM 142.
As stated above, the CRTM 142 and TPM 144 are presumptively trusted. Thus, following a platform reset, code in the Boot Block 150 is executed, which measures the entity to which it will transfer control, in this case, the Post BIOS 136. “Measuring an entity” means hashing object code in the entity to produce a log of the code, which is then extended into a platform configuration register (PCR) 148 in the TPM 144. The TPM 144 includes a plurality of PCRs 148, a portion of which are designated to the pre-boot environment and referred to collectively as boot PCRs 148a.Each boot PCR 148a is dedicated to collecting specific information related to a particular stage of a boot sequence. For example one boot PCR 148a (PCR[0]) stores measurements from the CRTM 142, POST BIOS 136, and all firmware 138 physically bound to the motherboard 130.
Once the POST BIOS 136 has been measured, control is transferred to the POST BIOS 136, which then continues to boot the system by ensuring that hardware devices are functional. Once POST BIOS 136 gains control, it is responsible for measuring any entity to which it will transfer control. As the POST BIOS 136 progresses through the boot sequence, values in the boot PCRs 148a increment whenever an entity is measured.
Upon booting to the operating system (OS) 114, the operating system 114 verifies the trustworthiness of the platform 120 by comparing the values in the boot PCRs 148a with precalculated values known by the operating system 114. If the values match, the operating system 114 is assured of a secure boot and that the platform is trusted. If the values do not match, the operating system 114 is alerted of a possible breach, and the operating system 114 can take measures to reestablish trust.
In FIGS. 2A and 2B, a flowchart illustrating a conventional boot sequence 200 in accordance with the TCPA trust model is presented. The method 200 starts 205 when the platform 120 is reset in step 210, e.g., the computer is powered-up, encounters a hardware reset or encounters a soft reset. In step 212, all boot PCRs 148a are reset to zero. Before the code in the Boot Block 150 is executed, the code may be measured, i.e., hashed to produce a log, which is then extended to the appropriate boot PCR 148a,via step 214. Then, in step 216, the code in the Boot Block 150 is run, which passes control over to the POST BIOS 136. Nevertheless, before executing the code in the POST BIOS 136, that code is also hashed and extended to the boot PCR 148a in step 218. Then, in step 220, the code in the POST BIOS 136 is run.
Referring now to FIG. 2B, the method 200 continues at letter B. The POST BIOS 136 locates any bootable devices in step 222 by reading each bootable device and attempting to find a valid boot record. When a valid boot record is discovered, the POST BIOS 136 measures the device and extends the value to the boot PCR 148a in step 224. Thereafter, in step 226, the code in the device is run. If this code determines that the boot is not a bootable device in step 228, control is then returned to the POST BIOS 136 to continue the booting sequence, via step 230.
If the device is a bootable device (step 228), an operating system 114 is booted 231. As explained above, each component is measured, i.e., the code in each device is hashed and extended to the appropriate boot PCR 148a.Thus, the values in the boot PCRs 148 reflect the boot sequence from beginning to end. In step 232, the operating system compares the value in each boot PCR 148a to a precalculated value that reflects a trustworthy boot sequence. The precalculated value is typically calculated by the operating system 114, which is aware of all trusted components.
If the boot PCR 148 values are equal to the precalculated value (step 232), the boot is finished 236. If the boot PCR 148 values are not equal to the precalculated value (step 232), the operating system 114 will initiate security checks to restore trust (step 238). The operating system 114 may examine the boot method to determine whether a security breach has occurred, for instance, by launching a virus detection program.
The trusted platform, as presented, offers significantly enhanced security over a traditional architecture if the system remains intact. However, as users become more mobile, there is an increasing risk that data and identity information on user systems may be compromised due to physical theft or loss. Whether the mobile computer is stolen for the sensitive data stored therein or for the hardware value is often unclear from the circumstances of the theft itself, typically, however, the owner must assume that efforts will be made to compromise the data stored thereon. One technique used to extract data is to remove the disk drive or other non-volatile memory and install the data repository on another system, which is designed to bypass security, and access the data thereon.
Cryptography has been used to secure the data in a data repository to protect against such attacks. A cryptographic key is then necessary to access the data stored in the data repository. Some systems typically create a clear partition containing boot data and the operating system and an encrypted partition containing all other data, accompanied by a utility that requests the user to input a cryptographic key. This system is open to attack by the substitution of a rogue operating system or programs masquerading as operating system components in the unencrypted partition. Of particular concern is the introduction of a snooper program that may record the cryptographic key. Even if the entire data repository is encrypted, a snooper program may be introduced into a rogue BIOS that may “steal” the key before the operating system can detect that the platform is insecure.
A need exists for a method, apparatus, and system that seals cryptographic keys associated with a data repository to a trusted platform. The sealing of cryptographic keys to a platform configuration will ensure that the data can be accessed only by the system that encrypted the data. The encrypted data may include one or more individual files, one or more partitions, or the entire disk volume. Sealing the cryptographic key of an entire encrypted volume will increase the security of the system startup, since the system will not boot if the BIOS, embedded firmware, or configuration has been compromised. Beneficially, such a process, apparatus, and system would permit unencumbered access to data in the data repository while it is an integral part of the trusted platform, but would prevent data access if the data repository were removed from the trusted platform, or if the trusted platform were compromised. The present invention addresses such a need.